Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9611/000082_owner-urn-ietf _Thu Nov 7 01:40:14 1996.msg

Internet Message Format | 1997-02-19 | 6KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id BAA23455 for urn-ietf-out; Thu, 7 Nov 1996 01:40:14 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id BAA23450 for <[e-mail]>; Thu, 7 Nov 1996 01:40:11 -0500
Received: from void.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA17992  (mail destined for [e-mail]); Thu, 7 Nov 96 01:40:07 -0500
Received: (from liberte@localhost) by ncsa.uiuc.edu (8.7.6/8.7.3) id AAA01984; Thu, 7 Nov 1996 00:35:39 -0600 (CST)
Date: Thu, 7 Nov 1996 00:35:39 -0600 (CST)
From: Daniel LaLiberte <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail] (Leslie Daigle)
Cc: Daniel LaLiberte <[e-mail]>,
        "Karen R. Sollins" <[e-mail]>, [e-mail]
Subject: Re: [URN] some comments
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
Reply-To: Daniel LaLiberte <[e-mail]>
Errors-To: [e-mail]

With all the activity on the URN list in just the last couple days, it
seems like ancient history to bring up the name-location issue again.
(You may have thought it was in the first place, but I think that
is the wrong perspective to take.  See below.)

Instead, I'll just clarify a couple things here (and I'll respond
briefly to a couple other postings later), and perhaps more
importantly I'll make some meta-comments on the process.  After that
Leslie and I and anyone else who wants to participate will thrash it
out off of this list and bring the result back.  Email me if you are
interested.

I do this not with resignation, but because I hope it will be more
effective.  I expect you will consider the issue "on hold" in the
meantime rather than decided by default.


Leslie Daigle writes:
 >
 > Dan,
 >
 > For all the words that have flown about on this mailing list in the past
 > few days, I don't really think you've made it clear what you want out
 > of this particular thread.

The issue came up when Karen expressed concern over the optional
"urn:" prefix.  Apparently, it doesn't help to make "urn:" optional
in an attempt to avoid the problems and subsequent discussion.

 > Let me be fairly blunt in my interpretation
 > here, and you can tell me on which counts I have misunderstood you.
 >
 > I think there are 2 separate things in what you have been saying:
 >
 >     . whether or not URNs are any different than URLs

Yes, that is the main thing we have been discussing.  Note: this is
equivalent to whether or not URLs are any different than URNs.

The issue also has to do with whether and how you bind an identifier
with its resolution mechanism.  So it is intimately related to (not
separate from) the second question:

 >     . whether or not URNs can be implemented using URL mechanisms

No, not exactly. In fact, I have said several times that I believe we
need the persistence being designed into the URN mechanisms, so it is
more pertinent to ask whether URLs can be resolved with URN
mechanisms.  (But there is more to it than that.)

 > Let me say, as co-chair of this working
 > group, that this WG starts from the premise that there _is_ a difference
 > between URNs and URLs, and that our chartered purpose is ...

This is largely a meta-comment:

Standing on premise and charter as an argument is legalistic and
dogmatic.  That's dangerous, although it may lead to short term
productivity.  If the IETF actually works this way now, it is in
danger of losing the valuable process which has made it work so well
so far.  Documented consensus should not be used as a wedge on future
possibilities but as a foundation upon which to build.  If it turns
out the foundation is flawed, do we attempt to fix it or build on it
anyway?

Even standards are revised over time, so why should a charter
be held up to be obeyed with more rigor?

 > ... To stick to our charter ... is a reflection of the fact that
 > this is a directed effort.

That has a positive ring to it.  All I'm trying to do is redirect the
effort a bit.  I wouldn't be here if I didn't think there was merit in
most of the effort.

How many people believe the "waterfall" approach to software
development should be followed strictly with never a revision or
retraction of the earlier steps along the way?  We are following the
waterfall model by establishing a charter, and similarly, by
establishing URN requirements, and then sticking to these earlier
decisions as if they were written in concrete.

I think a big part of the problem with this whole process is reflected
in partly why some IETF working groups have been dissolved.  Remember
"Rough consensus and working code".  We seem to be forgetting about
the working code part.  The value of the working code is that it
forces the issue of what makes sense in the real world.  Requirements
may crumble in the face of practical realities.

So how do we make progress while the foundation may be shifting?  It
is done in practice all the time, so I wouldn't worry about that too
much.  We may waste more time arguing over whether we should allow a
change in the foundation than just deciding what needs to be changed.

Karen has repeatedly expressed concern about making progress, and I
share that concern, but is coming to an understanding of the issues
not making progress?

 > > This is not a matter of just agreeing on a definition - it is a matter
 > > of having definitions that make sense.
 >
 > A relative term -- I think the definitions make perfect sense.

I'm willing to argue with you about what makes sense.  I'm not willing
to argue legalities.  Nor do I believe this is a religious issue in
the sense that it comes down to a matter of opinions. There is very
little religion in mathematics.

--
Daniel LaLiberte ([e-mail])
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/